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BACKGROUND OF THE INVENTION 
[0001] The Internet has opened up new channels of communication and 

vectors of influence over decision-making. Web sites, peer-to-peer technologies, e- 
mail and instant messengers are new communication technologies, which have major 
impacts. 

[0002] Advertisers and marketers have shown great interest in the influence of 

these new technologies. However, it is difficult to observe the channels of 
commvmication or vectors of influence using traditional market research methods. 
[0003] Users of the new communication technologies have been particularly 

quick to embrace instant messengers. Users desire new ways of sharing with friends 
the experiences they have and discoveries they make using the new communication 
technologies. 

[0004] Therefore, there is an opportunity to introduce a new technology, a 

method and device which provide a new way of sharing experiences, potentially 
allowing advertisers and marketers to study channels of communication and vectors 
of influence at the same time. 

SUMMARY OF THE INVENTION 

[0005] The present invention includes methods and devices for sharing 

communication device usage experiences, including computer usage experiences. 
Particular aspects of the present invention are described in the claims, specification 
and drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0006] Figure 1 is a block diagram of interrelated components of systems 

practicing aspects of the present invention. 
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[0007] Figure 2 is a user interface for logging in or creating a new account. 

[0008] Figure 3 is a user interface for providing access to system features. 

[0009] Figures 4 and 5 are user interfaces for inviting a "buddy" to join in 

practicing aspects of the present invention. 
5 [0010] Figures 6 and 7 are user interfaces for sending a buddy an item. 

[0011] Figures 8A-8D are aspects of a user interface for administration of a 

buddy list. 

[0012] Figure 9 is a user interface for viewing activity of buddies. The 

interface illusti-ated applies as well to viewing of other item or location related data, 
1 0 [0013] Figure 1 0 is a user interface for viewing a so-called hits list, combined 

with a user interface for viewing activity. The interface illustrated apphes as well to 
viewing of other item or location related data. 

[0014] Figure 1 1 is a user interface for viewing details regarding particular 

items. This user interface is combined, like figure 10, with a user interface for 
15 viewing activity. 

[0015] Figures 1 2- 1 4 is flowcharts illusti-ating the capture of URL related data 

from a user. The actions illustrated by these flowcharts apply as well to capture of 
other item or location related data. 

[0016] Figure 1 5 is a flowchart of automated updating of a visited URL 

20 database ("VUD"), with exception processing. The actions illusti-ated by these 

flowcharts apply as well to updating of databases reflecting captures of other item or 
location related data. 

[0017] Figure 1 6 is a flow chart of an activity viewer. The actions illustrated 

by these flowcharts apply as well to viewing of other item or location related data. 
25 [001 8] Figures 17-19 are flow charts of buddy list and access control hst 

("ACL") administration. 

[0019] Figures 20-21 is flow charts of access conti-ol list interface actions. 

[0020] Figure 22 is a flow chart of the batch and custom query processes. 

[0021] Figure 23 extends aspects of the present invention to wireless devices, 

30 such as cellular telephones and pagers. 

[0022] Figure 24 is a flow chart of populating the visited location database 

("VLD"). 
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DETAILED DESCRIPTION 
[0023] The following detailed description is made with reference to the 

figures. Preferred embodiments are described to illustrate the present invention, not 
to limit its scope, which is defined by the claims. Those of ordinary skill in the art 
will recognize a variety of equivalent variations on the description that follows. 
[0024] A common theme among aspects of the present invention is collecting 

data regarding a user's computer usage experience and sharing that data. So-called 
"buddies" identified on buddy Hsts of instant messaging products can share selected 
aspects of their computer usage experiences. Administrative tools and processes can 
be provided to set up selective collection and sharing of data. Collection tools and 
processes operate on a variety of computer usage activities and user responses to their 
computer usage experiences. Processing tools and methods filter, integrate and 
correlate the collected data. Display tools and processes make portions of the data 
accessible on a pre-defined basis, such as according to defined rights of buddies. 
Aggregation tools and processes assemble statistics about user experiences across 
different bases, such as buddy lists, categories of users, and all service participants. 
Data Compiled 

[0025] Aspects of the present invention include building and making 

accessible various databases and combinations of databases. The databases 
specifically described below are illustrated in one or another of the figures; reference 
numbers are provided for ease of reference. One database is a visited URL database 
("VUD") 1 OOA. A VUD stores URLs visited by users, or by participants. More 
generally, a user could visit a web site, listen to or watch content, rate a site or 
content, assign an emoticon or quick comment to a site or content, send or bookmark 
a site or content or download data; a VUD entry could result. A rating may be thumbs 
up or thumbs down or its equivalent, a scaled alpha or numeric rating or its 
equivalent. An emoticon is an icon conveying a reaction, such as: ":)", ":(", ":\", 
"=)"> "=(", etc. Quick comments may be user defined and later accessible through a 
menue, ush as a pull-down menu. In addition to URLs, the database stores additional 
information such as page title, address, description, categories applicable to the URL, 
metadata, names of users accessuig the URL, timestamps of visits, ratings of the 
URL, emoticons evaluating the URL, comments on and bookmarks to the URL, or 
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keywords for retrieval. The page title, address, description and metadata may be 
ascertained from visiting the URL itself. With assistance of the URL's author, 
metadata may include suggested categorization. Alternatively, categorization may be 
provided by an existing content analysis provider, such as Yahoo or the Open Source 
Directory Project at www.dmoz.org 1506. A further alternative is that content could 
be categorized by a service provider or other sponsor, either for web content or for 
intranet, extranet or other network content. 

[0026] Another database used to practice aspects of the present invention is 

the visited location database ("VLD") lOOB. A VLD stores similar information for 
locations visited by users or participants carrying portable devices. For instance, a 
Bluetooth equipped cell phone or pager could mteract with a location that a user 
entered. Walking in the door of a popular restaurant, nightclub or other location could 
trigger an interaction between a Bluetooth device and a Bluetooth access point 
sponsored at the location. The Bluetooth device could learn the location visited and 
report that location immediately or later when the device returned to the proximity of 
a home access point or the device docked with a home access point. Alternatively, 
the Bluetooth device could disclose its identity to a Bluetooth access point at a 
particular location and the access point could report the visit. The user of the 
Bluetooth device could have the same options for providing additional information 
regarding the location, as for URLs. The VLD also could store geographic 
information regarding the location, such as geo-coded data. Several equivalent 
methods of associating a portable device with a location are available. Sophisticated 
networks may fingerprint, triangulate or otherwise locate a wireless device based on 
radio signal characteristics. Sophisticated devices may include circmts that determine 
the device's location; these circuits may utiUze GPS, DGPS, Loran or any other 
location fixing protocol. The physics of how the device and the location are 
associated are relatively unimportant; an mdependent service may be used to track 
locations visited by a user based on any of the protocols identified above or any other 
protocol. 

[0027] The VUD and VLD databases are readily extended to a visited item 

database 100, which could include items on a computer, intranet, extranet or any 
network. These items may be data such as multimedia files, XML documents, 
database searches or virtually any other material. One distinction between practicing 
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aspects of the present invention and general database processing is storing user-based 
information, such as the user's pattern of visiting and the user's rating, emoticon or 
comments regarding an item and making stored, user-based information available to 
buddies. Collectively, VUDs, VLDs and visited item databases can be referred to as 
5 VXDs. Reference to one of the three VXDs is intended to refer to all three, unless the 
context makes it clear that only one of the three applies. 
[0028] Access control lists ("ACLs") 102, 103, 104, 1609 also can be 

maintained as databases. An ACL identifies buddies and controls their access to 
VUD, VLD, visited item and other activity-related data. A user could set up his or 
10 her ovra ACL via buddy list and access control list administration functions. An 

enterprise could set up ACLs for enterprise users. ACL-like data complied for instant 
messaging products could be accessed and utilized to compile ACLs for users or 
enterprises. 

[0029] A URL logo database ("ULD") 101 can be usefiil for associating logos 

15 with web sites. The logos maybe sponsors, advertisers or others who provide support 
for operation of a service practicing aspects of the present invention. 
[0030] Item categorization for VUD, VLD or visited items can generate 

exception databases, such as an item match exceptions database (for instance, a URL 
match exceptions database ("UMED") 1505) or a topic match exceptions database 
20 ("TMED") 1507. These exception databases record data which require fiirther 

attention after initial processing to update the VUD, VLD or a visited item database. 
[0031] An activity viewer database ("AVD") 1610 can store information 

associating particular users with URLs, locations or items. Raw data regarding user 
activity is filtered and matched with entries from the VUD, VLD or visited item 
25 database to create the AVD. The AVD holds users' activity parsed into a format for 
display via the Activity Viewer. It includes the activity, internal flag settings, the 
URL, the page title, the logo, the usemame, the timestamp & category for an entry. If 
a user filters the display of data on the Activity Viewer, data is pulled from this 
database. 

30 [0032] Batch query results can be stored in a database, a "BQD" 2211. Pre- 

defined queries can be run against the VUD, VLD or visited item database. For 
instance, top 10 hits, top 50 hits or top 100 hits in a wide range of categories are most 
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efficiently recalculated periodically on a batch basis, rather than in response to ad hoc 
inquiries. 

[0033] Third party location detection data can be stored in a detection network 

directory 2312. Third party data can be provided as received, on an interrupt-like 
5 basis, or in response to periodic requests, on a polling or batch basis. Location 

categorizations and descriptions 2413, e.g., Yellovt^ Pages.Com, AutoDesk, etc. can be 
used to provide supplemental information about locations. 

[0034] Location/topic entries which require further attention, after processing 

to update the VLD, can be stored in another match exceptions database, a "LTMED" 
10 2414. 

[0035] One aspect of practicing the present invention can include tying into a 

user's instant messaging products or, more generally, into the user's messaging 
facihties. For instant messaging ("IM"), users or participants typically set up so- 
called buddy lists. Other users or participants agree to participate in instant 

1 5 messaging. One IM user can send an instant message to another IM user, if their IM 
products are compatible. The two can carry on a dialog or a so-called "chat". More 
than two users may be included in a real-time chat, when the instant messaging 
product allows multiple participants. Examples of instant messaging products include 
AOL's Instant Messenger software, MSN Messenger software, Yahoo! Messenger 

20 software, America Online' s ICQ software, Odigo's instant messenger software and 
Jabber's instant messenger software. Reciprocal inclusion on buddy lists typically 
involves a closer relationship between participants than inclusion on an e-mail 
mailing list or directory, but this is not necessarily the case. Buddy lists sometimes 
are shorter and more selective than general messaging lists or directories. 

25 [0036] The present invention also may be applied to a user's messaging 

facilities by selectively enabling others listed on a general e-mail or messaging Hst or 
directory to participate. Selectively enabling others limits the intrusion on a user's 
privacy and limits various administrative (e.g., setup and administration) and 
responsive (e.g., junk mail) burdens. Alternatively, group functions used for other e- 

30 mail or messaging purposes can be a basis for defining rights to sharing of activity 
data. 
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Overview and User Interfaces 

[0037] Figure 1 is a block diagram of interrelated components of systems 

practicing aspects of the present invention. Tracked activity may include Internet 
activity 120, wireless network location track and interaction activity 121 and 
5 enterprise intranet activity 122. Activities tracked in these domains may include 
view, listen, rate, comment, assign emoticon, send, watch, download, bookmark or 
visit. A user views a URL, watches a visual presentation and listens to an audio 
presentation. A user visits a restaurant or other location. A user who views, watches, 
listens or visits may respond to their experience. A user's response may be to rate, 
10 comment, assign an emoticon, send information to a buddy, download data or 
bookmark an item for later access. 

[0038] Data stored regarding an experience may include VUD, VLD or VXD 

databases 100, a logo database for URLs, locations or items 101 and a variety of ACL 
databases. The access control lists can be maintained at the service provider level 

15 104, the enterprise level 102 or the individual user level 103. 

[0039] Data 130 reflecting individual experiences and aggregated experiences 

can be accessed or reported in a variety of ways. An activity viewer ruiming on a 
user's system 131, either fixed or portable, can appear in a window. Reports on 
locations, either the experiences of others visiting the location or the proximity of 

20 buddies or buddies of buddies can be reported automatically to Bluetooth enabled 
wireless devices 132 when such devices reach a location or are in contact with a 
location-sponsored Bluetooth access point. Wireless devices can be synchronized 1 33 
when reasonable bandwidth is available to retain data that would be too voluminous 
to access via a low bandwidth connection. The interfaces of instant message tools 

25 134 can serve as an output channel, as licensing arrangements become available. 

Physical reports 135 can be printed for analysis. These reports can cover analysis of 
interactions among participants and spreading of information from one user to others. 
[0040] Figure 2 is a user interface for logging in or creating a new account. In 

one embodiment, separate fields can be provided for user name 25 1 and password 

30 254. In other embodiments, these fields could be combined. After filling in 

identification data, a user may select a sign on link 253 or press the enter, return key 
or other key or may take another action such as speaking a command or winking an 
eye, which triggers processing of the completed fields. A link is provided for creating 
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a new user 252, which may be on demand or subject to an approval process. A new 
user can either be a new name for a registered user or a new registration. A user who 
forgot their password may use one of the commonly employed password recovery 
schemes, by selecting a forgotten password link 255. An additional link for new user 
5 registration is provided 256. In one embodiment, the system implements a strict, 
anonymous access privacy policy and does not collect any information about the user 
which could be used for identification of the user or compilation of a database of user- 
identified activities. In another embodiment, the user can chose the amount of 
information that the user provides and corresponding services that are enabled by 

1 0 providing information such as an e-mail address. In this second embodiment, the 

system can publish a range of privacy policies, including a default, and ask the user to 
opt-in to a specific privacy policy, which may include providing the user's name or e- 
mail address to a handful of select vendors that have products responsive or keyed to 
the user's shared activities. 

1 5 [0041] Figure 3 is a user interface for providing access to system features. 

The embodiment illustrated is a relatively low profile access window. A lower profile 
access window can be provided via an icon that is visually accessible, such as a 
floating menu bar having an always on top attribute or an icon in a system tray. 
Pressing a hot key is an alternative way to bring an access window into view. The 

20 access window illustrated in Figure 3 has many featiires, which can be included in a 
wide variety of combinations. The service provider logo 360 doubles as providing 
access to features not immediately visible. These features may include maximize, 
minimize, quit or selection of a particular display format. A current selection 361 
identifies a current context, such as viewing an aggregated list of the best Hip Hop 

25 music of 2000. Rating choices 362 such as thumbs up and thiunbs down or emoticons 
allow a user to instantly express their view regarding the current context with a simple 
action, such as a single click of a mouse. A user who wants to say more about their 
experience can select a comments button 363 to activate a window for entering 
comments. A scroll button 364 also supports entry of fi-ee form comments, definition 

30 of user comments, selection firom among user comments, or selection of emoticons, 
either system supplied or user defined emoticons. When the scroll button 364 is used, 
the default item may change from "comments." Other button choices 363 can be 
provided to a user, in addition to comments, such as emoticons or sending the current 
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context to one or more buddies. A send button 365 is immediately accessible and 
activates a window for selecting recipients of information from the current context. 
The current context may be a list or a particular item, either from a hit list or the like 
or from the user's own activities. 

[0042] The sharing status toggle 366 allows a user to turn sharing on and off. 

When sharing is on, rights defined in the ACL provide access for buddies to the user's 
activity. When sharing is off, the user's activity will not be shared with buddies. 
However, the user's activity may still be recorded to a tracking server either for 
aggregation or to be associated with the user but not reported to buddies. The user's 
options or access to information may be limited when sharing is off, tending to 
encourage the user to leave sharing activated. The window maximize control 367 
allows direct access to maximizing the window to a pre-selected format. 
[0043] Other aspects of this interface include space for a banner 368 (either 

static or moving), an invite button 369, a hot list access 370, a search entry window 
371 and a search button 372. The banner could be used to generate advertising 
revenue. The invite button 369 provides access to an invite interface such as figure 4. 
The hot list access 370 provides access to one or more options and access formats for 
aggregate ratings of items. The ratings may reflect the frequency of access to an item 
or rating scores assigned by users. The rating scores may be thumbs up/down or any 
of the other scoring approaches mentioned above. The search entry window 
371accepts text and logical connectors. The find button 372 can be implemented to 
search titles of items accessed by participants, content of such items, the Internet, an 
intranet or another domain of interest. 

[0044] Figures 4-5 are aspects of an interface for inviting others to become 

buddies. Figure 4 is one of many possible initial invitation interfaces. An instant 
messaging select button 473 allows a user to identify an instant messaging product 
which maintains a list of buddies who can be invited to join a group. In some 
implementations, such as an enterprise implementation, a network directory such as a 
Novell, NT or Windows 2000 server directory of users may be accessed instead of an 
instant messaging product. In other implementations, an e-mail system user directory 
may be accessed for users to invite. Group membership for enterprise 
implementations alternatively may be administered by a security department, instead 
of individual users. A scroll button 474 allows a user who has more than one source 
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of lists, such as more than one instant messaging product, to select the user to be 
invited. The screen name window 475 accepts a text string. It may provide assisted 
field completion, including a list of near matches. For some implementations, such as 
AIM or Yahoo IM, the screen name may be a name. For other implementations, such 
as Indigo and ICQ, the screen name may be a number which ties to a name, which 
may be locally unique or not unique at all. These alternatives are further presented in 
the discussion of figure 1 7, below. A send button 476 triggers transmission of an 
invitation to the identified buddy or other potential participant. The transmission may 
include a text message delivered by the instant messaging tool with a hyperlink for the 
recipient to sign up. The done button 477 signals that the user is done inviting 
buddies. A more information button 478 provides a help function. 
[0045] Figure 5 is an invitation follow-up interface. In some embodiments of 

the invitation process, there is no feedback from the instant messaging tool to an 
invitation process. The invitation process may query the user to determine whether an 
invitation was sent successfully. This interface provides a user with three alternative 
responses. If the instant message transmission was successful, the user indicates 
"yes" 582. If the user attempted the instant messaging invitation, but the buddy was 
not available, the user may press the e-mail link 581 . Alternatively, the user may 
elect to invite the buddy again later 583. Then, the buddy's name will appear on a 
buddy administration Hst (Figure 8A) with a link such as "resend invitation." The 
system may allow a user to clink on an entry in a list and resend the invitation, 
preferably when the invitee is on line. In other embodiments or using other instant 
messaging products, the IM product may assure delivery of the message when the 
recipient is not instantly available. Yet another approach is for the IM product to 
provide direct feedback to the activity sharing processes, so that an invitation or other 
follow-up interface appears only when needed and so that the user never needs to 
confirm that an invitation or item was successfully sent. 

[0046] Figure 6 depicts an interface for sending an item to a buddy. This 

interface may be invoked, for instance, by selecting the send button 365. The item 
being sent is identified 691 . The item identification 691 may be linked to the item, a 
pull-down menu of items recently viewed or recently sent, or to a dialogue for 
selecting an item to send. The user selects between sending the item, a link to the 
item or other item-related information to a buddy who has enrolled to share activity 
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data or to a person listed as an instant messaging buddy. In an enterprise 
implementation, as described above, the user might select an addressee from a 
network registry of users or an e-mail list. A personal note 695 may be sent along 
with an item. The system may be configured so that the personal note is not retained 
5 on the tracking server or so that it is retained. The send item button 696 signals that 
the items should be sent. The cancel button 697 indicates that the item is not to be 
sent. Either the send or cancel button can be accompanied by a confirmation screen. 
[0047] Figure 7 is a confirmation interface for items sent. The three choices 

are as in figure 5: to confirm that the message was sent 799 "yes"; to resend the item 

10 by e-mail 798; or to queue it to be resent later 799 "later." 

[0048] Figures 8A-8D depict interfaces for administration of buddy Hsts. The 

embodiments depicted are adapted to integration with instant messaging products. 
Slightly different embodiments would be better adapted to e-mail or other types of 
messaging facilities, such as Lotus Notes. Figure 8A depicts one embodiment of a 

1 5 buddy list. A link is provided 85 1 for inviting a new buddy. An alternate link for 
adding a user may appear in the list of buddies 856. The colimms provided in this 
embodiment include a tick box 852, a buddy name 853, and one or more instant 
messaging contact links 854. The tick box 852 may be used to delete several selected 
buddies. The buddy name column 853 includes both buddy names and options to 

20 resend an invitation or add a new user. The buddy names may be active links which 
lead to additional interfaces, such as those depicted in figures 8B-8D. The contact 
column 854 lists one or more instant messaging contact links. The extension 
following the link may identify a particular instant messaging tool. The link may be 
in the form of the user ID applicable to a particular instant messaging tool. This 

25 interface also includes a link for deleting selected buddies 857 and for indicating 
completion of buddy list administration 858. 

[0049] Figure 8B is another of the buddy list administi-ation interfaces. The 

name of the buddy being profiled appears as a header 861. Optionally, a group of 
buddies may be administered. Related buddy administration screens include a buddy 
30 overview screen 862, contact information 863, topic sharing rights 864 and file 

sharing rights 865. The user may either view 866 or edit 867 information regarding a 
buddy or group of buddies. More information can be obtained by clicking a link 868. 
For particular buddy, a particular instant messaging tool is selected 869 and instant 
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messaging ID is entered or selected 870. When a buddy has more than one instant 
messaging tool or ID, a user may select a link for adding additional links 871 . The 
interface adds more rows, including more options for instant messaging tools and 
instant messaging ID's 872, 873. More than one instant messaging ID may be 
5 assigned to a buddy for a particular instant messaging tool. When the contact 
information is complete, the user selects the save changes link. 
[0050] Figure 8C uses tick boxes to select files or folders to be shared by 

default. Both default and particular user or user group administration is supported. 
Tick boxes 881 and directory or file names 882 can be used. Additional files or 
1 0 folders can be added to a list 883. Alternatively, a Windows Explorer- style file 

directory tree can be used to select files and directories, as is done for backing up and 
restoring files or directories. Additional fields and links in Figure 8C have the same 
placement and usage has in Figure 8B. 

[0051] Figure 8D is a topic sharing interface. Both default and particular user 

15 or user group administration is supported. Tick boxes 891 and topic or sub topic 

names 892 can be used. Additional topics can be added to a list 893. Alternatively, a 
browser-style bookmark tree can be used to select topics. Additional fields and links 
in figure 8B have the same placement and usage as in the previous figures. 

Flowcharts 

20 [0052] Figure 9 is a user interface for viewing activity of buddies. The 

interface illustrated applies as well to viewing of other item or location related data. 
Tab 963 indicates that the activity- viewing mode of the interface is currently active. 
Other tabs may be provided for people 962, files 964, messages 965 or summaries 
966. The people tab 962 may invoke buddy list administration. The files tab 964 may 

25 invoke a hierarchical representation of the user's file system and selection boxes for 
designating directories and files, relative to particular buddies. The buddy may 
appear as columns adjacent to the file system representation or with a separate list, 
with selection boxes for users to be associated with particular rights. The message tab 
965 may provide access to a message repository. Button 961 provides access to 

30 commands such as minimize, maximize, always on top, etc., which were previously 
discussed in the context of Figure 3. The sharing button and indicator 967 behaves as 
previously described, also in the context of Figure 3. In this embodiment, additional 
controls are provided in a row below the tabs and sharing button. Three filters 971, 



Page 12 of 36 



FatB 1000-1 



972 and 973 are provided. The who filter 971 specifies whose activity is of interest: 
for instance, all buddies or a user-defined group of buddies. The topic filter 972 
selects one or more pre-defined topics. The view filter 973 allows viewing of all or 
selected portions of a participant's activity by topic. For instance, only items 
5 bookmarked or sent to others may be of interest, in a domain having substantial 
activity. A keyword search is in effect a fourth filter, including the search term 
window 974, the find button 975 and the advanced find button 976. 
[0053] Several rows of information responsive to the filters 971-976 appear in 

Figure 9. The columns of information displayed for each row include who 981 did 

10 892 what 984 where 985 in what topic area 982 when 988. Ratings 986 and 

comments 987 also may be provided. This interface can convey a substantial amount 
of information compactly. The who column 981 may use short labels, especially 
when the buddy list is short or subgroups of buddies are created. The did column 982 
is compactly represented by an icon, from a recognizably short list of activity types. 

1 5 The icons depicted in this figxire may signify viewing , visiting and sending items. 
Each of the activities mentioned above may be assigned an icon. The topic column 
983 also is compactly represented by an icon. The variety of topics may be larger 
than the variety of activities. User defined subtopics may complicate the selection of 
icons. In some instances, a user may need to access more detailed information about 

20 an activity in order to understand the topic involved. This detailed information may 
be available through the topics filter 972 or by selecting a particular line including the 
icon. The what column 984 is an informative title for the item identified. For a URL, 
a page title may be more informative than the URL. Accordingly, page titles may be 
stored for URLs, to guard against loss of the page title when a content provider 

25 updates the page. Similarly usefiil shorthands for other types of items may be used. 
For instance, the name of a restaurant may be used instead of its Bluetooth access 
point address. The where column 985 is an opportunity to display banners, which 
may generate user impressions and revenue. Display of banners may be limited to 
vendors who pay a fee for preferential banner display. The rating column 986 may 

30 use a graphic, a color or a symbol to indicate a rating. In this embodiment, icons for 
thumbs up/down are depicted. The thoughts coltimn 987 may support either free text 
comments or pick-list comments such as emoticons or user-defined quick comments. 
The when coliimn 988 records a date and time of an activity. A send button 989 is 
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included. In this embodiment, it appears as a large button on a bottom row, instead of 
as an icon near the sharing button. Row select commands, such as mouse-click, shift 
mouse-click and control mouse-click can be used to select one or more rows prior to 
selecting the send button. 

[0054] Figure 1 0 is a user interface for viewing a so-called hits list, combined 

with a user interface for viewing activity. The interface illustrated applies as well to 
viewing of other item or location related data. The bottom part of this interface 
combines features found in Figures 3 and 9. Much of the two rows 1070 is taken 
from Figure 3. The who filter 1081 is from Figure 9. The item rows 1071 are 
generally as in Figure 9, with an added column for send buttons 1082. Next and 
previous buttons 1084, 1085 are provided for scrolling through activities. 
[0055] The top part of the Figure 1 0 interface is a hits list. The title line 1 05 1 

identifies the category of hits, in this instance a Top 10 list. Filter buttons are 
provided for activity type 1052, group of persons sampled 1053 and location of 
persons sampled 1054. When the desired filters are selected, the submit button 1055 
signals for the screen to be refreshed. Three columns of information about these 10 
hits are provided in this embodiment: rank 1061, what 1062 and where 1063. These 
columns have been explained above, except the ranking, which is ordmal. The 
coincidence in this example between data lines in the top 1 0 list and in the activities is 
unlikely ever to occur at random in actual use; the repeat of the same lines twice in a 
top 10 list also is imlikely to occur in actual use. 

[0056] Figure 1 1 is a user interface for viewing details regarding particular 

items. This user interface is combined, like figure 1 0, with a user interface for 
viewing activity. The bottom part of this interface, 1070, 1071, is as m Figure 10. 
The top part includes two windows: 1151 through 1 1 54 and 1 1 55 through 1167. The 
larger frame in the top part displays search results, annotated with buddy-related 
information. The search string appears at the top 1 155 along with summary search 
statistics 1158. Both category results 1 1 56 and individual items have been returned in 
this example. One category 1156 has been returned. Three items responsive to the 
search have been returned, each beginning with a title 1 157. Information for an item 
may include a buddies rating 1161. The number of buddies of the user who have 
commented on the site is indicated parenthetically. A summary "thumbs up" is 
indicated and a percentage of favorable ratings appear. (In actual use, 78% would not 
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be reported from a sample of three ratings.) In addition to user-buddy ratings, other 
group ratings can be reported. In this instance, ratings aggregated against all 
registered users 1 162 are reported. The second group could be user selected. In an 
enterprise implementation, it could be a division, subsidiary, a whole enterprise or any 
other predefined group. The ratings 1 1 6 1 , 1 1 62 need not be up-to-the-moment 
ratings, they may be compiled periodically in a batch mode. The information for an 
item may include a site furnished text 1 163, a review furnished description 1 164, one 
or more categories applicable to the item 1 165 and links for retrieving a cached copy 
1 1 66 or similar pages 1 1 67. The cached copy retrieval 1166 may be an alternative to 
retrieving a live copy of the item 1 157, which is useful when an item is deleted or 
moved after it is indexed. 

10057] The inset to Figure ll,1151-54,is intended to provide detailed 

information related one or more of the items displayed. The columns of detailed 
information in this embodiment include who 1 151, when 1 152, rating 1 153, and 
comments or emoticons 1 154. If there are more users then can readily be displayed in 
a single inset, previous and next buttons can be used to scroll through a list. 
Alternatively, the list can be sized into a larger window. The list also could be filtered 
to select particular buddies or groups of buddies, date ranges, ratings or comments. 
The names of individual users and their comments can be linked to additional 
information or functions related to the individual and to the detailed free text 
comments. 

[0058] Figures 12-14 are a flowchart illustrating the capture of URL related 

data from a user. The actions illusfrated by this flowchart apply as well to capture of 
other item or location related data. Figures 12 and 13 are linked by the capture/track 
connector 1233. Figures 13 and 14 are linked by the file & item connector 1355. The 
flow in Figure 12 begins with start 1201. The user may visit a URL 1202 utilizing 
any browser, from a PC, telephone, PDA or other device. Others processes described 
in the context of visiting or viewing a URL, it may be applied to other item types as 
well. The URL visited is captured 1203. This capture may be accomplished via a 
browser plug-in, an independently ruiming process, or in a variety of other ways. A 
page titie or other descriptive text may be captured in addition to the URL address. 
The page title or other text is stored in a temporary variable, along with a timestamp 
and a user ID. In this embodiment, the capture process next has to determine whether 
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in the user's sharing status is on 1204. If the sharing status is off 1205, the system sets 
the status of the item to private. In other embodiments, the system might all 
processing of the item. If the sharing status is on 1206, tiie system sets the status of 
the item to public. After the status is been sent, the process tests to determine whether 
5 metadata associated with the URL provides a page title 1207. If not 1208, the system 
stores a null indicator in a temporary variable. 

[0059] If the metadata provides a page title 1209, the system stores the page 

title in a temporary variable. The system next compares the URL to entries in the 
VUD 1210. If the URL is found in VUD 12 11, the system has to determine whether a 

1 0 page title is stored on the VUD 1 22 1 . If there is a page title on the VUD 1 222, the 
system action depends on whether the page title variable has been set to null. If not, 
the system over writes the value on the VUD with the value of the temporary page 
title variable 1224. If the temporary page title variable is null, the page title stored on 
the VUD is used 1223. Next, the system determines whether the URL has been 

15 categorized on the VUD 1225. If not, the system sets a temporary category variable 
to uncategorized 1227. This is the same action that the system takes in the URL is not 
on the VUD 1211. If the URL has been categorized on the VUD, the system sets a 
temporary category variable based on the contents of the VUD 1226. The system 
checks to determine if the URL or a portion of the URL is logged in a logo database 

20 1228. The logo or ULD database 101 holds vendor logo images that correspond to 
the vendor's URLs. If the vendor has not arranged for its logo to be stored on the 
VLD 1229, the system sets the temporary local variable to null 1231. If there is a 
corresponding logo, the temporary variable is set to the corresponding logo image 
1230. The system sets a temporary activity variable to view 1232, corresponding to 

25 viewing a URL. The flow continues in Figure 13. 

[0060] Figure 13 depicts processing of URLs behind the interfaces presented 

above. The user has several options after viewing a URL. Viewing the URL triggers 
background activities depicted in figure 12. While the user is viewing the URL, 
system monitors for activity 1341. If no activity is detected 1342, monitoring 

30 continues. When activity is detected, the system determines the type of activity 1 343, 
1345, 1347, 1349, 1351, 1353. When the user moves to a new URL 1343, the values 
stored in temporary variables for the old URL are added to the VUD 1344. The new 
URL is processed in accordance with figure 12. When the user selects an emoticon 
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1345, the system processes the user's selection 1 346. The system may associate either 
a predefined emoticon with the URL or it may associate a user-defined emoticon with 
the URL. These values may be stored in a temporary variable until the user moves to 
a new URL or another user activity triggers storing data to the VUD. When the user 
5 decides to enter a free text comment 1347, the system processes the free text 1348. It 
associates a text string with the URL at a temporary location, which can later be 
transferred to the VUD. The system then resumes monitoring for URL activity 1341 . 
The user selection of rating 1349 is processed 1350 in much the same way as an 
emoticon. In the embodiment described here, the rating is either thumbs up for 

10 thumbs down, a binary rating. Multi-value ratings can also be processed, such as a 
scale of 1 to 5, 1 to 7, or 1 to 9. The system then resumes monitoring for URL 
activity 1341. Choosing the send button 1351 causes two processing steps 1352. One 
or more items in the current context are sent to a buddy and the activity of sending the 
items is reported to a tracking server to be recorded in the VUD. The system then 

1 5 resumes monitoring for URL activity 1341. Processing that follows detection of a 
bookmark activity 1353 is similar to processing of a send activity. Either the instant 
messaging product or the system may process the actual creation of the bookmark. 
The activity of creating the bookmark is reported to a tracking server to be recorded in 
the VUD 1354. Again, the system then resumes monitoring for I/O activity 1341. 

20 Other activities, more often associated with an item other than a URL, are processed 
as depicted in figure 14. 

[0061] A variety of activities may be associated with items other than URLs. 

Depending on the type of item involved, the user may listen to or watch the item 
1461, download the item 1463, purchase the item 1465, put the item on a wish list 

25 1467, transfer the item to a mobile device, such as a cell phone or PDA 1469, or select 
some other process 1471. In some circumstances, an unrecognized activity may occur 
1473, which the system may either ignore or treat is an error condition. A listen to or 
watch activity 1461 causes the system to invoke a player and to record the action and 
properties of the item listened to or watched 1462. The recorded information is 

30 forwarded for addition to the VUD. A download activity invokes a process, which 
records the download action and properties of the item downloaded 1464. The 
recorded information is forwarded for addition to the VUD. A purchase activity 1465 
invokes a process 1466, which records the purchase action and properties of the item 
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purchased. The recorded information is forwarded for addition to the VUD. A wish 
list activity 1467 invokes a wish list process 1468 to maintain and add to the user's 
wish list. The wish list can be maintained as part of the VUD or in a separate 
database. The information can be maintained redundantly as part of the VUD and as 
5 the result of a batch query. When the activity is to transfer the item to a mobile 

device 1469, the system invokes a process for sending the information to the mobile 
device, records the action and properties of the items sent to the mobile device, and 
forwards the recorded information for addition to the VUD 1470. The processing of 
each of these activities in figure 14, with the possible exception of error processing 

10 1 473 , leads back to monitoring for activity 1341. 

[0062] Figure 1 5 is a flowchart of automated updating of a visited URL 

database or VUD, with exception processing. The actions illustrated by these 
flowcharts apply as well to updating of databases reflecting captures of other item or 
location related data. An automated VUD updating routine 1511 updates keywords 

1 5 and metadata 1512 and topics 1513. The input for updating is a set of VUD update 
records from processing of user activity. Updating 1514 may take place and real-time 
or on a batch basis. The updating of keywords and metadata utilizes a URL spider 
and an external search engine index to gather URL indices, keywords and metadata 
for each VUD entry being updated from the Internet 1 522. Unmatched entries are 

20 stored in an exceptions database 1505 and an exception report 1521 is generated. 
Data m the exceptions database ("UMED") may be manually added to the VUD. 
These exceptions also can be reprocessed for instance, if Internet access is restored or 
improved. Additional processing takes place to update topics associated with VUD 
entries 1513. During processing 1515, the system compares VUD entries against one 

25 or more external URL categorization databases, such as the database provided by the 
Open Source Directory Project (www.dmoz.org). Matches are processed for addition 
to the VUD. VUD entries that do not match are marked as on categorized and stored 
in an exceptions database 1507. Data in this topic exceptions database ("TMED") 
may be added manually to the VUD or reprocessed any time. Additional items to the 

30 exceptions database may cause an exceptions report 1523 to be generated. 

[0063] Figure 16 is a flow chart of an activity viewer. The actions illustrated 

by this flowchart apply as well to viewing of URL, other item or location related data. 
The activity display population routine 1621 supports the interface 1629, which 
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previously has been discussed in the context of Figure 9. The system keys 1622 on 
fields which provide access to the relevant database, such as the VUD, VLD 100 or 
VXD. For VUD entries, user ID and topic may be used as a key. Alternatively, the 
key may be fields which match filters available to or selected by the user. For a 
5 visited location, user ID and location or action may be used as a key. The system 
1622 matches data fi"om the relevant database 100 with the user ACL database 1609. 
This matching may run periodically on a schedule set by the system administrator or it 
may run on demand. Data "matches" when the ACL database authorizes the requester 
or a particular user to have access (e.g., by user ID and topic) to the VXD entry and 

10 the status flag is public (as opposed to private) for the VXD entry. Matched data 
items are buffered 1623. For each buffered entry 1624, the system checks- for the 
existence of a logo on the location logo database ("LLD") 1608. Processing depends 
on whether or not a logo exists 1 625. If it exists, the system sets a temporary variable 
corresponding to the logo image retrieved firom the database 1 626. Otherwise, the 

15 logo space is left blank. Each matched entry is added 1627 to the corresponding 
shared users file within the activity viewer database ("AVD") 1610. The system 
populates activity viewers of logged-in users by pulling entries fi-om the AVD 1628. 
User ID, action, item, location, category, rating, emoticon, comment, time, or other 
relevant field may filter the displayed data firom the AVD. The activity viewer of the 

20 user refi-eshes the activity display automatically. The firequency for this refiresh may 
be set by a system administrator and may be modified by the user. 
[0064] Figures 17-19 are flow charts of buddy list and access control list 

("ACL") administration. The after the administration processes invoked 1721, the 
process tests to determine whether the user of the system is a new user 1722. A new 

25 user may either be invited or not 1 725. An invited user is prompted to a start their 
buddy list with the person who and issued the invitation 1731. If the new user adds 
the person who invited them 1732, the new user optionally defines access rights 1735. 
The system then sets flags for new and invited status to "no" 1736. The system adds 
the buddy and associated information in the user's buddy list to the ACL 1 734 and 

30 loops back to the start 1 72 1 with the user flagged as not new. In the processing of the 
new user, if the new user is not invited 1725 or declines to add the person who invited 
them to the new user's buddy list 1732, an error message is displayed indicating that at 
least one buddy must appear on a buddy list 1726. The user is routed to an add buddy 
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screen 1733. This add buddy screen 1733 also may be reached by a non-new user 
who has an empty buddy list 1723 through the invite buddy error message 1726 or 
after the non-new user is shown their current buddy list 1 724 and elects 1727 to add 
additional buddies. Processing of a non-new user who declines to add additional 
5 buddies proceeds to 1728, in Figure 18. After the add buddy screen, the system 
checks the user's IM tool flags to determine which instant messaging tools are 
available and to provide an adapted message to the user 1734. The user's options 
1738 may include asking for more information, canceling the addition of users or 
selecting an instant messaging tool such as AIM user, ICQ user, Odigo user or Yahoo 

10 IM user. The user may be required to confirm my pressing an OK button after 

selection of an instant messaging tool. If the user presses OK 1741, instead of cancel, 
the system tests to determine whether the user requests more information 1742 and 
provides an information screen 1745 upon request. The system also tests to determine 
whether the user requests shared topics information 1743 and provides an information 

1 5 screen 1 746 on request. After information has been provided the system tests 

determine whether the user has selected one of the instant messaging options 1744. If 
not, the system loops and waits 1741. If an instant messaging tool has been selected, 
the system determines which class of instant messaging tool has been selected 1 752. 
For some instant messaging tools, the system displays a name field 1754 and prompts 

20 the user to enter a name 1 756. For other instant messaging tools 1751, the system 

displays a user number field and prompts the user to enter a buddy number 1753. For 
both classes of instant messaging tools 1755, the user optionally defines access rights. 
Processing then continues to test for inviting a new buddy 1757, as described in 
Figure 19. 

25 [0065] Figure 1 8 includes logic for editing entries in the buddy list, following 

other processing 1 728. The system checks to determine whether one or more buddies 
have been selected 1 861 . If not, processing 1862 returns to a previous screen. If a 
buddy has been selected, processing depends on the number of buddies in the list 
1863. If there are one or fewer buddies in the last 1864, the system activates only the 

30 end button. If there is more than one buddy in the Hst 1 866, the system activates edit 
and remove buttons. The remove button is not activated for one or fewer buddies, as 
the system requires at least one buddy in a buddy list. The system checks to 
determine whether edit has been selected 1 867. If not, it checks to determine whether 
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remove has been selected 1868. If not, processing returns to the start 1865. If remove 
has been selected 1869, the system displays a confirmation screen and tests vi^hether 
the remove command has been confirmed 1872. If not, the system loops again to test 
whether remove has been selected 1 868. If confirmation is given 1 874, the system 
5 removes one or more buddies from the user's buddy list and returns to the start 1 865. 
Remove will not have been selected if edit is selected 1871 . The system responds to 
selection of edit with an edit user screen 1871. The user responds to the screen by 
editing any the fields of the selected buddy and clicking submit or cancel. The system 
tests to determine whether submit has been selected 1875 and, if so, tests to determine 

1 0 whether mandatory fields have been completed 1 877. Mandatory fields may include 
the identity of the instant messaging tool and a user ID, either a name or user number, 
as appropriate. If some of the mandatory fields are incomplete, an error screen 1876 
is displayed and the user is given a further opportunity to add any of the fields 1873. 
If the mandatory fields are completed, the system updates the buddy and associated 

1 5 information in the buddy Hst 1878 and returns to the start 1 865 . If the user clicks 

cancel instead of submit or otherwise fails to submit 1875, processing proceeds to test 
whether remove has been selected 1868. The processing from this point proceeds as 
described above. 

[0066] Figure 1 9 depicts logic for sending invitations to new prospective 

20 buddies. This logic complements other interface processing 1757. The system 
determines whether the user has selected the send invitation link 1982. If not, 
processing returns to the start 1981. If so, the system checks to determine whether the 
user being invited is already registered for services 1984. The system uses the 
prospective buddy's IM tool ID as a key. If the prospective buddy has more than one 
25 IM tool, the system may either use only a primary IM tool ID or may use all listed IM 
tool ID'S to check for current registration status. If the prospective buddy is not 
registered 1985, the system invites the buddy by invoking the user's instant messaging 
tool and creating a message with standard text and a link to invoke a regisfration 
process 1983. The system queues the invited prospective buddy in a file of pending 
30 invitations 1 986. The invited buddy's ACL and instant messaging ID will be stored 
against a temporary registration ID. When the invited buddy responds to the 
invitation, the system will use the temporary ID to match the invitee against the 
queue. After an invitation has been made, the system marks the user's buddy list as 
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not empty 1989 and sets the user's new and invited flags to "no". For a the 
prospective buddy 1985 who is already registered, the system notifies the user of the 
prospective buddy's status 1987 and stores the buddy name with relevant information, 
such adds an identification of the instant messaging tool used by the buddy 1988. The 
5 system adds the buddy and associated information to the user's buddy list 1990. The 
system allows the user to send messages to the buddy, including a message regarding 
their ACL status 1991. Either the user's instant messaging tool with standard text and 
links or an e-mail message may be used for this purpose. The system sets the user's 
new and invited flags to "no" 1992 and returns to start 1981. 

10 [0067] Figures 20-21 are a flowchart for access control list administration. In 

Figure 20, ACL administration begins with a start screen 205 1 . One sensible default 
organization is by topic 2052. In the "by topic" view, the system checks 2053 to 
determine whether a "by buddy" view has been selected. If so, logic for displaying 
and processing the "by buddy" view is invoked 2054. If not, the system checks to 

1 5 determine whether the administration session has been canceled 205 5 . If "cancel" has 
been selected, the system determines whether the page has been marked as amended 
2056. If the page has not been amended, the system returns to a previous screen 
2050. If it has been marked as amended, the system prompts the user to save changes 
2057 and tests whether the user wants to save changes. If not, the system simply the 

20 reverts to a previous screen 2050. If so, the system updates various access flags and 
related data 2066 before reverting to the previous screen 2050. When "cancel" has 
not been selected, the system checks whether a topic folder has been selected 2059. If 
so, the system shows the corresponding buddy Ust access level in a pane of the view 
screen 2060. The system then determines whether tick boxes adjacent to any buddy 

25 name have been checked 2061. If so, the display format of the buddy name may be 
altered to reinforce the tick mark and the page is marked as amended 2062. 
Processing continues to determine whether a buddy name has been de-selected 2063. 
If so, the display format of the buddy name may be altered to reinforce to the de- 
selection and page is marked as amended 2064. Processing continues to determine 

30 whether "submit" has been selected 2065. If not, processing loops to before 2053. If 
so, the update path 2066 is followed. 

[0068] In Figure 2 1 , ACL administration proceeds from selection of the "by 

buddy" view 2054. This view is displayed 2172. The system determines whether the 



Page 22 of 36 



FatB 1000-1 

user has selected a change of view to "by topic", for instance. If so, the display is 
changed 2171. If not, the system determines whether the user has selected "cancel" 
2175. If "cancel" has been selected, the system determines whether the page has been 
marked as amended 2176. If the page has not been amended, the system returns to a 
5 previous screen 2 1 74. If it has been marked as amended, the system prompts the user 
to save changes 2177 and tests whether the user wants to save changes 2178. If not, 
the system simply the reverts to a previous screen 2174. If so, the system updates 
various access flags and related data 2186 before reverting to the previous screen 
2174. When "cancel" has not been selected, the system checks whether a buddy 

1 0 folder has been selected 2179. If so, the system shows the corresponding topic list 
access level in a pane of the view screen 2180. The system then determines whether 
tick boxes adjacent to any topic name have been checked 2181. If so, the display 
format of the topic name may be altered to reinforce the tick mark, and the page is 
marked as amended 2182. Processing continues to determine whether a topic name 

1 5 has been de-selected 21 83 . If so, the display format of the topic name may be altered 
to reinforce the de-selection and the page is marked as amended 2184. Processing 
continues to determine whether "submit" has been selected 2185. If not, processing 
loops to before 2173. If so, the update path 2186 is followed. 
[0069] Figure 22 is a flow chart of the batch and custom query processes. 

20 Batch processing of requests 225 1 may be useful to reduce response time for certain 
processing-intensive queries. For instance, scoring the top 10 or top 100 hits in a 
category may require a substantial amount of processing which the user would be 
unlikely to endure. The selection of a hit Hst may be from a menu, which means that 
the number of processing-intensive queries is limited and manageable. The system 

25 performs predefined queries 2252 against the VUD 1 OOA and the VLD 1 OOB or any 
similar database on a batch basis. The results are sent to a database of batch query 
results ("BQD") 221 1. These predefined queries are accessible immediately to both 
Internet and wireless network queries. Figure 22 distinguishes between Internet 
queries 2253 and wireless queries 2255. Internet queries may include both predefined 

30 queries and custom-buih queries 2254. To the extent that wireless queries are 

hampered by limited bandwidth, wneless queries may be limited to predefined queries 
2256. The processing of both types of queries is essentially the same 2257. The user 
submits a query to the system and the system either performs or real-time query 2258 
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or retrieves a predefined query from the batch query database 2259. The system 
returns results of the query to the user 2260. 

[0070] Figure 23 extends aspects of the present invention to wireless devices, 

such as cellular telephones and pagers. Processing of wireless location and action 
5 data begins at 235 1 . The user's wireless communication device and location detection 
service is first activated 2352. It is necessary for the user to have a wireless device 
2354, which supports a location detection service. This support may be by Bluetooth, 
GPS or any other location detection technology. Then, the link between location 
detection and activity sharing is activated 2353. A login process may be automated to 

1 0 execute whenever the wireless device 2354 is activated. Given the activation of a 

wireless device, the system periodically receives information regarding the location of 
the wireless device 2356. As described above, this may be on an interrupt, polling or 
periodic batch transfer basis. A location network directory 2312 is accessible, which 
reflects location of wireless devices 2354 and contains information such as the 

1 5 devices' location address, location description, a timestamp, and user ID 2358. With 
this information, the system sets the action or activity type to "visit" a location and 
logs an entry into a visited location database 2358. The system also monitors 2355 
for activity related to a location, such as bookmarking a location, rating a location, 
adding an emoticon or comments about the location. Activity monitoring 2355 

20 continues when no input/output activity is detected 2357. When input/output activity 
is detected, the system determines the type of activity. Typical activities include 
bookmarking 2359, rating, or adding an emoticon 2363 or free text comment to a 
location reference. When a location is bookmarked 2359, the system adds a 
bookmark flag, location address, location description, a timestamp and a user ID to 

25 the VLD or a buffer for later addition to the VLD. When a location is rated 2361 , the 
system adds the rating, location address, location description, a timestamp and the 
user ID to the VLD or a buffer for later addition to the VLD. When a location is 
flagged with an emoticon 2363, the system adds the emoticon, location address, 
location description, a timestamp and the user ID to the VLD or to a buffer for later 

30 addition to the VLD. Similarly, when a user makes a comment on a location 2365, 
the system adds the comment, location address, location description, a timestamp and 
the user ID to the VLD or to a buffer for later addition to the VLD. For each of these 
activities, fewer or more fields may be utilized in various embodiments. 
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[0071] Figure 24 is a flow chart of populating the visited location database 

("VLD"). The process for updating topics and descriptions begins at 245 1 . The 
system compares 2452 all VLD entries or buffer entries for addition to the VLD 
against location category and location description database entries 2413. It updates 
5 the matching entries and records to categorization and descriptions to the VLD. 

Unmatched entries are recorded in an exceptions database 2414. This location-topic 
and location-description match exceptions database ("LTMED") may be used to 
generate an exceptions report 2453. Matched entiies are written to the VLD lOOB. 

Application Examples 

1 0 [0072] The interfaces and software described above support many methods 

and devices for sharing commimication device and computer usage experiences. One 
type of sharing communication device user experiences is sharing computer usage 
experiences, including Internet browsing experiences. Whichever communication 
device is used, sharing may depend on registration by a user with a registration server. 

1 5 Registration may involve downloading client software to run on the user's system. 

For enterprise applications, registration may be handled by a system administrator and 
integrated or coordinated with registi-ation for network login, e-mail or other 
messaging. In some embodiments, registration may include contractual terms which 
hmit the use of information collected from the user. In other embodiments, 

20 registration may be designed to exclude collection of certain user information, such as 
the user's e-mail address, actual name or physical address. Some users may feel more 
comfortable registering with the system if registration excludes collection of any 
information that identifies the user in a manner adapted to direct marketing. Even if 
registration excludes initial collection of user identifying information, the user may be 

25 given the option of entering additional personal information for general use by the 
providers of the system or for restricted use, in accordance with contractual terms. 
The registration process may make the user aware that at least a portion of the user's 
experiences with a communication device, computer or Internet browser will be 
collected and shared. It also may make the user aware that information collected from 

30 the user will be aggregated with information collected from other users. 

[0073] Sharing commimication device experiences also may include accessing 

one or more messaging buddy lists associated with the user. Accessing pre-existing 
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buddy lists provides a base for linking the user and buddies with whom tracking data 
may be shared. Buddy lists may be maintained by AOL's Instant Messenger software, 
MSN's Messenger software, Yahoo! Messenger software, America Online's ICQ 
software. Indigo's instant messenger software or Jabber's instant messenger software. 
5 More generally, message recipient lists maintained in e-mail systems, such as 

Microsoft's Outlook products or AOL's Netscape products may maintain the lists that 
are accessed. Messaging systems such as Lotus Notes also may maintain message 
recipient lists that the system can access to identify persons with whom tracking data 
may be shared. 

1 0 [0074] Buddies or groups of buddies are given defmed rights to access 

tracking data collected from the user. Defmed rights of buddies to access fracking 
data may be based on content categories of material accessed. Examples of content 
categories or topics can be found in figure 8D. Defmed rights of buddies also could 
be based on keywords. Definition of rights to access tracking data collected from the 

1 5 user may have multiple aspects. Access may be restricted by the type of activity 
involved, such as viewing, listening, rating, commenting, assigning an emoticon, 
sending, watching, downloading, bookmarking or visiting. Access may be further 
restricted by when the activity potentially accessed took place. It may be restricted 
based on a value assigned to a rating or emoticon. It can also be restricted based on 

20 its original source. Activities marked private, instead of public, may never be shared, 
based on a user's decision to turn sharing off. There are many useful combinations of 
these approaches to define the rights of buddies or groups of buddies to access 
tracking data. 

[00751 At least a portion of the user's computer usage experiences are tracked 

25 and reported to a tracking server. This tracking may be carried out by a module 

resident on the user's computer or by a device placed between the user's computer and 
an access point to the Internet. In an enterprise implementation, tracking can be 
carried out by a server or proxy server. The fracking data can be filtered before it is 
reported to the fracking server. Data may be filtered based on a sharing on/off option 
30 exercised by the user. It also may be filtered based on content categories. In some 

implementations, only those activities that fit content categories which the user agreed 
to share would be reported to the fracking server. Alternatively, activity could be 
reported to the tracking server that was never intended to be posted for access by 
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buddies. The tracking server or a posting server could filter the information before 
posting it for buddies to access. The computer user experiences tracked could include 
viewing URLs, downloading files, listening to songs, viewing videos, making 
purchases, sending items from a user to their buddies, or general messaging between 
5 the user and buddies. 

[0076] In addition to computer user experiences, mobile communication 

device locations can be tracked, using any of the technologies described above. 
Activities related to location may include visiting the location, rating, commenting on 
it, assigning an emoticon, or coimecting with another buddy or buddy of a buddy at 

1 0 the location. Proximity to a location may be variation on visiting the location. 

[0077] It further may be usefiil to categorize at least a portion of the tracking 

data by content. The categorized tracking data would be subject to filtering and 
sorting. Categorized tracking data also could be searchable by content category and 
date range. For instance, a particular buddy's viewing of stock-related sites containing 

15 the name "Cisco" during a one or two-month period could be located. 

[0078] Tracking data can be posted, after filtering, for buddies to access 

according to their defined access rights. The interface for viewing activity reflected 
by the tracking data may include a send button, which allows a user to forward an 
item to a buddy, either with or without comment. Interface also may include rating an 

20 emoticon buttons. It may facilitate fi-ee text comments on an item. These functions 
may apply to selected groups of items, in addition to applying to individual items. 
The buttons for free text comments and the feature for adding notes to items sent to 
buddies allow annotation of items. 

[0079] The tracking process further may include generating a fiill text index of 

25 items viewed. This indexing may be performed in the context to viewing URLs or, in 
an enterprise implementation, in the context of the viewing internal work product or 
summaries of internal work product. Automated some regeneration may be combined 
with indexing, so that summaries are indexed. 

[0080] Additional functionality of the system, which passively tracks 

30 activities of registered users may include tracing the flow of information or data 
among registered users. Information which is sent from a user to a buddy may be 
annotated with a history of users who forwarded the information. Alternatively, it 
may include a first user who forward the information and the immediately previous 
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forwarding user. Or, it could identify a limited number of previous forwarding users. 
If less than a will history of users who forwarded the information is included with 
information sent from a user to a buddy, an analysis server may use a combination of 
timestamps and forwarding information to determine the dissemination or diffusion 
5 information and the velocity at which it is disseminated. Social network theory 
provides a number of metrics for evaluating the dissemination or diffusion of 
information. The tracking capabilities which are an aspect of the present invention 
can readily be adapted to quantifying the relative influence of one or another user on 
their buddies, including the strength, frequency, extent and relative value of their 

10 influence. Certain users may be selected for introduction to information or new 

product releases. Certain users may be selected and rewarded as a result of efficient 
dissemination of information through their social network. 
[0081] A system practicing aspects of the present invention can readily 

collect, collate and present user generated lists of superlatives regarding activities, 

1 5 products and services. List may be generated by time period, utilizing date stamps 
and activities, nxmiber of top items (10 or 50 or 100 top items) or other filtering 
criteria. 

[00821 The availability of location information for mobile communication 

devices allows the system practicing aspects of the present invention to present 

20 information regarding buddies and buddies of buddies who may be present at the 
user's physical location. Based on tracking visits to locations, information can be 
generated such as a particular user's list of favorite restaurants or favorite boutiques. 
Patterns of visits to physical locations can be reported. Information can be presented 
to users based on locations recently visited. 

25 [0083] Information associated with particular locations can be offered up to 

users of mobile communication devices, in a context sensitive mode. Categories of 
information such as buddies' ratings of nearby restaurants can be provided, utilizing 
location information generated from the mobile communication device and 
established buddy lists. 

30 [0084] While the preceding example applications are cast in terms of a 

method, devices and systems employing this method are easily understood. A 
magnetic memory containing a program capable of practicing the claimed method is 
one such device. A computer system having memory loaded with a program 
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practicing the claimed method is another such device. A system including a 
registration server and a tracking server practicing the methods described above is 
another such device. 

[0085] While the present invention is disclosed by reference to the 

5 embodiments and examples detailed above, it is imderstood that these examples are 
intended in an illustrative rather than in a limiting sense. It is contemplated that 
modifications and combinations will readily occur to those skilled in the art, which 
modifications and combinations will be within the spirit of the invention and the 
scope of the following claims. 

.0 

We claim as follows: 
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